>> Correct me if I'm wrong, but don't game engines "usually" use an 
>> invisible skeleton rather than the actual visible polygon mesh for 
>> collision detection purposes? (Precisely to simplify the problem and 
>> make it tractable in realtime.)
> 
> No, you're completely correct, in fact I'm already doing that in my 
> game.

Yay for me!

> The problem I have now is that because my physics loop runs at 100 
> Hz and some objects are moving quite quickly (like a metre per physics 
> step) it's hard to determine exactly where the collision took place, and 
> hence calculate the correct impulse to stop them intersecting at the 
> next step.  I don't have enough CPU cycles spare to roll back the 
> simulation with a finer time step, so I'm just using some hackery to 
> estimate it for now.

I was under the impression that this is pretty much standard procedure; 
compute the path of an object for the next few split seconds and see if 
it intersects the path of anything else. Otherwise objects would have to 
collide exactly on the bounderies of your time steps - which is, uh, 
"improbable". ;-)

> It works ok most of the time, and things bounce 
> and spin off nicely in 3D, but occasionally one object visibly goes 
> inside another for a bit.

That's nothing! With the Havok physics engine, sometimes objects hit the 
ground and flail around indefinitely. (Presumably the engine trying to 
prevent the object intersecting the ground.) Sometimes objects just keep 
jiggling and won't stop - and sometimes the movement is quite significant.

> I'm sure with a bit more hackery I can make 
> it more robust without having to do more physics steps.  Then I need to 
> optimise the collision *detection*, as it gets a bit slow when 10 or so 
> objects are colliding simultaneously.

Uh, yeah, I have no idea how to fix that...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message